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By including environment information in a security policy, 
a security architecture advantageously allows temporal, 
locational, connection type and/or client capabilities-related 
information to affect the sufficiency of a given credential 
type (and associated authentication scheme) for access to a 
particular information resource. In some configurations, 
time of access, originating location (physical or network) 
and/or connection type form a risk profile that can be 
factored into credential type sufficiency. In some 
configurations, changing environmental parameters may 
cause a previously sufficient credential to become insuffi- 
cient. Alternatively, an authenticated credential previously 
insufficient for access at a given trust level may be sufficient 
based on a changed or more fully parameterized session 
environment. In some configurations, the use of session 
tracking facilites (e.g., the information content of session 
tokens) can be tailored to environmental parameters (e.g., 
connection type or location). Similarly, capabilities of a 
particular client entity (e.g., browser support for 128-bit 
cipher or availablity of a fingerprint scanner or card reader) 
may affect the availability or sufficiency of particular 
authentication schemes to achieve a desired trust level. 
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SECURITY ARCHITECTURE WITH 
ENVIRONMENT SENSITIVE CREDENTIAL 
SUFFICIENCY EVALUATION 

BACKGROUND 

1. Field of the Invention 

The invention relates to information security, and more 
particularly, to systems and method for improving the secu- 
rity of information transactions over networks. 

2. Description of the Related Art 

The internet has become an important medium for infor- 
mation services and electronic commerce. As the internet 
has been commercialized, organizations initially established 
their presence in cyberspace by making information 
(typically static, non -sensitive promotional information) 
available on resources well removed from the operational 
infrastructure of the organization. Security issues were often 
addressed by isolating publicly accessible resources (e.g., 
web servers) from more sensitive assets using firewall 
techniques. As long as the publicly accessible information 
and resources were relatively non-sensitive and user inter- 
actions with such information and resources was not mission 
critical, relatively simple firewall techniques were adequate. 
Though information and resources outside the firewall were 
at risk, the risk could generally be limited to non -proprietary 
information that was easily replaceable if compromised. 
Proprietary information and systems critical to day-to-day 
operations were sheltered behind the firewall and informa- 
tion flows across the firewall were filtered to exclude all but 
the comparatively non-threatening services such as elec- 
tronic mail. 

However, as the internet has become more pervasive, and 
as the sophistication of tools and techniques has increased, 
several aspects of the security environment have changed 
dramatically. First, businesses have recognized the power of 
information transactions that more tightly couple to opera- 
tional data systems, such as order processing, inventory, 
payment systems, etc. Such transactions include electronic 
commerce with direct purchasers or consumers (e.g., 
browsing, selecting and purchasing of books by members of 
the public from an on-line bookseller) as well as supply 
chain and/or business partner interactions (e.g., automated 
just-in -time inventory management, customer-specific 
pricing, availability and order status information, etc.). 
Commercially relevant transactions increasingly require 
information flows to and from secure operational systems. 
Second, even information-only services are increasingly 
mission-critical to their providers. Corporate image can be 
adversely affected by unavailability of, or degradation 
access to, otherwise non -sensitive information such as cus- 
tomer support information, product upgrades, or marketing 
and product information. Because many businesses rely 
heavily on such facilities, both unauthorized modification 
and denial of service represent an increasing threat. 

Individual information service or transaction system typi- 
cally exhibit differing security requirements. While it is 
possible to field individualized security solutions for each 
information service or transaction system, individualized 
solutions make it difficult to maintain a uniform security 
policy across a set of applications or resources. Furthermore, 
individualized solutions tend to foster incompatible security 
islands within what would ideally be presented to consumers 
or business partners as a single, integrated enterprise. For 
example, a user that has already been authenticated for 
access to an order processing system may unnecessarily be 



?1,232 Bl 

2 

re -authenticated when accessing an order status system. 
Worse still, a set of individualized solutions is typically only 
as good as the weakest solution. A weak solution may allow 
an enterprise to be compromised through a low security 

5 entry point. 

Another problem with individualized solutions is a veri- 
table explosion in the number of access controls confronting 
a user. As more and more business is conducted using 
computer systems, users are confronted with multiple iden- 

30 tifiers and passwords for various systems, resources or levels 
of access. Administrators are faced with the huge problem of 
issuing, tracking and revoking the identifiers associated with 
their users. As the "user" community grows to include 
vendors, customers, potential customers, consultants and 

15 others in addition to employees, a huge "id explosion" faces 
administrators. Furthermore, as individual users are them- 
selves confronted with large numbers of identifiers and 
passwords, adherence to organizational security policies 
such as password restrictions and requirements (e.g., length, 

20 character and/or case complexity, robustness to dictionary or 
easily- ascertainable information attack, frequency of update, 
etc.) may be reduced. As users acquire more passwords — 
some individuals may have 50 or more — they cannot help 
but write down or create easy-to-remember, and easy-to- 

25 compromise, passwords. 

SUMMARY 

Accordingly, a security architecture has been developed 
in which a single sign-on is provided for multiple informa- 

30 tion resources. Rather than specifying a single authentica- 
tion scheme for all information resources, security architec- 
tures in accordance with some embodiments of the present 
invention associate trust-level requirements with informa- 
tion resources. Authentication schemes (e.g., those based on 

35 passwords, certificates, biometric techniques, smart cards, 
etc.) are associated with trust levels and environmental 
parameters. In one configuration, a log-on service obtains 
credentials for an entity commensurate with the trust-level 
requirements) of an information resource (or information 

40 resources) to be accessed and with environment parameters 
that affect the sufficiency of a given credential type. Once 
credentials have been obtained for an entity and have been 
authenticated to a given trust level, access is granted, 
without the need for further credentials and authentication, 

45 to information resources for which the trust level is sufficient 
given a current session environment. In some configurations, 
credential insufficiency may be remedied by a session con- 
tinuity preserving credential upgrade. 

By including environment information in a security 

50 policy, facilities in accordance with some embodiments of 
the present invention advantageously allow temporal, 
locational, connection type and/or client capabilities-related 
information to affect the sufficiency of a given credential 
type (and associated authentication scheme) for access to a 

55 particular information resource. In some configurations, 
time of access, originating location (physical or network) 
and/or connection type form a risk profile that can be 
factored into credential type sufficiency. In some 
configurations, changing environmental parameters may 

60 cause a previously sufficient credential to become insuffi- 
cient. Alternatively, an authenticated credential previously 
insufficient for access at a given trust level may be sufficient 
based on a changed or more fully parameterized session 
environment. In some configurations, the use of session 

65 tracking facilites (e.g., the information content of session 
tokens) can be tailored to environmental parameters (e.g., 
connection type or location). Similarly, capabilities of a 
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particular client entity (e.g., browser support for 128-bit FIG. 1 is a block diagram illustrating information flows 

cipher or availablity of a fingerprint scanner or card reader) between components in a security architecture with envi- 

may affect the availability or sufficiency of particular ronment sensitive credential sufficiency evaluation in accor- 

authentication schemes to achieve a desired trust level. Of dance with an exemplary embodiment of the present inven- 

course, not all advantages need be provided in any given 5 tion. 

implementation. FIG. 2 is a flow chart illustrating operation of a security 

In one embodiment in accordance with the present architecture with environment sensitive credential suffi- 

invention, a method of determining sufficiency of a creden- cienc y evaluation in accordance with an exemplary embodi- 

tial type for access to an information resource includes ment of the present invention. 

establishing a correspondence between a session and an 10 FIG- 3 illustrates interactions between functional compo- 

access request targeting the information resource, establish- nents in a functional decomposition of a security architec- 

ing a trust level requirement for access to the information ture with environment sensitive credential sufficiency evalu- 

resource, and evaluating correspondence of one or more ation in accordance with an exemplary embodiment of the 

credential types with the trust level requirement for access to present invention. 

the information resource and with environment information 15 FIG. 4 illustrates relations between login credentials, 

associated with the session. session credentials and a cookie encoding of a session token 

In another embodiment in accordance with the present «> accordance with an exemplary embodiment of the present 

invention, a method of operating a security architecture invention. 

includes matching an access request of a client entity with a The use of the same reference symbols in different draw- 
corresponding session. The access request targets a first of 20 ings indicates similar or identical items, 
plural information resources and the session has an associ- DESCRIPTION OF THE PREFERRED 
ated one or more session parameters affecting sufficiency of EMBODIMENTS) 
credential types. The method further includes determining a „ .,>., 
set of one or more credential types sufficient for access to the Som f terminology used in this specification has meaning 
first information resource. The determining is based, at least 25 Pf"^ l ° the context of embodiments described herein, 
in part, on the one or more session parameters. If an Therefore to aid persons of ordinary skill in the art in 
authenticated credential associated with the session is of one understanding the full scope of the invention, some of that 
of the sufficient credential types, then access to the first terminology is now defined, 
information resource is allowed. Otherwise, a new credential ossary 

is obtaining, the client is authenticated entity thereby, and 30 f Access Management: Systems, methods and techn.ques 

access to the first information resource is allowed. The for controlliiig use of information 'resources. Typically 

obtained credential is of one of the sufficient credential access management systems employ both authentication and 

t authorization to control access to information resources. 
, " .„ , , . - , , Authentication: A process used to verify the identity of an 
In still another embodiment in accordance with the 35 entity. As typically implemented, an authentication method 
present invention, an information system includes plural fe { d to verif the identit of a meT or object based 
information resources hosted on one or more servers on a cred ential supplied by the user or object, 
coupled v ia a communication network to a client entity and Authorization: A process for determining whether an 
an access control facility common to the plural information ^ fc iUed t0 rform MIM action , such as access . 
resources. The plural information resources have individu- 4Q { a resource Typically, an identity will be authenticated, 
ahzed authentication requirements and the common access m fa ^ SQme configurations certain identities need not be . 
control facility obtains a credential for the client entity and Credential: Evidence of identity used to authenticate an 
authenticates the client entity thereby. In response to a cmi E } credentials types include passwords, cer- 
request for access to a first of the information resources, the lificates Qf omef e ted indicia based oa asymmetric, 
common access control facility evaluates, based m part on 45 etric , public , private , or se^t key technologies, one- 
current parameters of a corresponding persistent session, time ordSj biomet ric indicia such as by retinal scan, 
sufficiency of associated authenticated credentials for access yoice ^ finger ^ ^ ^ possession based indicia 
to the first information resource. such as smaft cards> £mgma cards> keyS) etc In SQme 
In still yet another embodiment in accordance with the realizations, credentials may be associated with users, 
present invention, an access control facility for providing a 50 sessions, functional objects, etc. 

single sign-on for sessions that potentially include accesses Digital Signature: A transformation of a message using an 

to plural information resources having differing security asymmetric cryptosystem such that a person having the 

requirements includes an application proxy and means initial message and the signer's public key can accurately 

responsive to the application proxy for evaluating sufifi- determine whether the transformation was created using the 

ciency of credential types based on then current parameters 55 private key that corresponds to the signer's public key and 

of the session and on a trust level requirement of the targeted whether the message has been altered since the transforma- 

information resource. The application proxy configured for tion was made. 

receiving an access request targeting one of the information Entity: A user or object, including data objects and/or 

resources, associating the access request with a session, and functional objects such as applications, components, 

selectively proxying the access request if at least one suf- 6n modules, services, processes, threads, etc., as well as instan- 

ficient credential is associated with the session. tialions thereof. In some configurations, only user entities 

(typically, the human principal interacting with a software 
program or on whose behalf a software agent purports to act) 

The present invention may be better understood, and its are considered. In other configurations, entities include 

numerous objects, features, and advantages made apparent 65 functional objects without an associated human principal, 

to those skilled in the art by referencing the accompanying The identity of an entity may be authenticated using a 

drawings. credential. 
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Session: A period and collection of states spanning one or authorization component 140 to obtain authorization for 
more interactions between an entity and an information access to a particular requested enterprise application or 
environment. As used herein a session may span multiple information resource by the requesting entity (e.g., the 
interactions with multiple resources of the information envi- browser user). If the entity requesting access has not yet 
roument and, in some configurations, may span multiple 5 Deen authenticated to the trust level required for the par- 
information access protocols (e.g., HTTP, FTP, telnet, etc.). ticular access lo the particular enterprise application or 
A session has a beginning and an end. During its existence, information resource requested, authorization component 
a session has state. As used herein, the term session connotes 140 may indicate that the access request ^ t0 be redirected 
a greater persistence than as sometimes used to describe the tQ j ^ component 120 so that 2 m cre dentials may be 
period of a session layer protocol irtoaction, which in the w obtained and authenticated to a particu i ar trust level. If, on 

short liveT 6 ^ S ' ^ * ^ 86116 the 0ther hand ' l0 ® n «dential8 have already been obtained 

SbgkSign-on Security Architecture for u lhe ^™f™2 «*ity and the requesting entity has been 

FIG. 1 provides an overview of major interactions authenticated using the obtained credentials such that the 

between components for an exemplary security architecture re 9 uired trust level has beeo achieved, the access will 

in accordance with the present invention. As illustrated in 15 typically be allowed without the need for further login 

FIG. 1, a client application, e.g., a browser 170 operated by credentials and authentication. In certain circumstances, 

a user, interacts with the security architecture via a gate- authorization component 140 may indicate that the access is 

keeper and entry handler component 110 and a login com- to be refused. For example, authorization component 140 

ponent 120. Gatekeeper and entry handler component 110 may be programmed to perform more stringent testing 

provides an entry point for external client applications 20 beyond a trust level requirement. In an exemplary enterprise 

requesting access to enterprise applications and/or resources tool configuration, a desired security policy may dictate that 

190, including e.g., information resources 191, 192 . . . 193, a salary tool is accessible only from with a company's 

for which access management is provided by the security internal network. No level of authenticated trust may be 

architecture. Using facilities provided by a session manage- sufficient to access such a tool from outside company 

ment component 160, an authorization component 140, an 25 network. To facilitate implementation of such a security 

authentication component 130, an identification component policy, authorization component 140 could refuse access 

150, and login component 120, the gatekeeper/entry handler based on environment parameters indicating a session origi- 

component 110 allows, redirects or refuses access requests nating outside the company's internal network, 

in accordance with a security policy. Of note, in certain embodiments in accordance with the 

Individual information resources typically have differing 30 present invention, the mapping of login credential types and 

security requirements. In addition, individual types of access authentication mechanisms to trust levels is influenced by 

to a single information resource may have differing security environment information such as time of request, source of 

requirements. Nonetheless, a given level of security may be request, connection speed, and/or client application (e.g., 

sufficient for more than one of the information services or browser) environment information. In this way, even with a 

access types. For example, information resource 191 may 35 static set of mapping rules, the set of credential types and 

include a product information service for providing general . authentication mechanisms suitable to support a given trust 

information such as product descriptions or data sheets to level may vary based on environment information. In 

the public, while information resource 192 includes an order general, mapping rule dependencies are based on perceived 

processing system for an eCommerce site. Information variations in threat characteristics and/or requesting entity 

resource 193 may include functions for supply chain inter- 40 capabilities. In some embodiments in accordance with the 

actions such as access to inventory information or current present invention, gatekeeper/entry handler component 110 

selling price information. Both the product information is the authority on environment information for a particular 

service and order intake functions of the eCommerce may requesting entity. 

operate with similar security requirements, e.g., allowing In some embodiments, mapping rules may be dynami- 

access by minimally authenticated, non-hostile entities. On 45 cally varied. For example, if a particular login credential 

the other hand, supply chain functions may require a higher type and/or authentication method is deemed insecure (e.g., 

level of security. Order status functions of the order pro- because compromised or because of a changing threat 

cessing system may require a mid -level of security. profile), the trust level mappings can be updated and have 

Login component 120, operating in conjunction with enterprise- wide effect. In addition, several other advantages 

gatekeeper/entry handler component 110 and other compo- 50 are achieved by defining the authentication requirement 

nents of the security architecture, provides a single sign-on interface between enterprise applications and/or resources 

interface for access to enterprise applications and/or and the security architecture in terms of required trust levels, 

resources 190. In an exemplary embodiment, security rather than in terms of particular credential types and 

requirements are expressed in terms of trust levels and login authentication methods. First, single sign-on configurations 

component 120 obtains login credentials for an entity 55 are facilitated using an enterprise- wide credential obtaining, 

requesting access to one of the enterprise applications and/or authentication and session tracking infrastructure. Second, 

resources 190. The login credentials obtained are selected authentication requirements may be enforced uniformly in 

from a set of credential types that, if authenticated, are accordance with an enterprise -wide security policy and with 

sufficient to achieve the trust level requirement of an appli- reduced vulnerability to a lax security implementation by 

cation or information resource to be accessed. Without 60 any particular information resource. Third, credential types 

limitation, typical login credential types and associated and authentication methods can be added, deleted, or 

authentication mechanisms include those based on mapped to a new trust level, all without modification of 

passwords, certificates, biometric techniques, smart cards, enterprise applications and resources. Of course, all advan- 

etc. Other credential types and associated authentication tages need not be achieved in any particular implementation, 

mechanisms are described elsewhere herein. 65 In certain embodiments in accordance with the present 

In some embodiments in accordance with the present invention, a credential upgrade facility is provided. In 

invention, gatekeeper/entry handler component 110 queries response to an access request from an entity for which login 
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credentials have already been obtained and authenticated, vate Network (VPN) low-level encryption, etc.) may be 

but for which the obtained and authenticated login creden- obtained from incoming requests themselves or based on a 

tials are insufficient for the trust level associated with the particular entry point (e.g., a particular router or port). More 

requested access, authorization component 140 may indicate generally, gatekeeper/entry handler component 110 obtains 

that the access request is to be redirected to login component 5 and/or maintains information such as connect location (if 

120 so that sufficient login credentials may be obtained and ascertainable), temporal information such as request time/ 

authenticated to the required trust level. Of note, credential dale, session start time/date, etc. (preferably in both the 

upgrade facilities in accordance with certain embodiments client entity's frame of reference and the security architec- 

of the present invention allow upgrade without loss of ture or requested information resource's frame of reference, 

session continuity. 30 if location is ascertainable), and client type and/or capabili- 

Excmplary Configuration ties (e.g., browser type and Java Development Kit (JDK) 

Referring to FIG. 1, an entity (e.g., a browser 170 level). In some configurations, information on line speed, 
operated by a user) interacts with enterprise applications origination point (e.g., inside or outside of a corporate 
and/or resources 190 and the security architecture via a network), browser type, encryption capability, number of 
gatekeeper/entry handler component 110 and a login com- 15 hops, latency, system type, etc. may be gathered. Such 
ponent 120. In general, a wide variety of entities, including information is used in some configurations for mapping 
human users operating browser and/or non-browser client particular authentication mechanisms to trust levels and for 
applications as well as automated agents and systems, may authorization decisions. Environment information is gener- 
interact with enterprise applications and/or resources 190 ally packaged into a data structure that is associated with a 
and the security architecture as described herein. 20 client session. Other components of the security architecture 
Furthermore, a variety of information resource identification may add additional client environment information, such as 
schemes, such as by Uniform Resource Locator (URL), authentication strength or current trust level, 
resource address, identifier or namespace designation, may Gatekeeper functionality (e.g., in gatekeeper/entry han- 
be employed. However, for purposes of illustration and not dler component 110) checks whether a session is already 
limitation, an exemplary interaction involving a browser and 25 associated with the incoming request. Although other tech- 
information resources identified by URL is described in niques are possible, in some configurations in accordance 
detail. Nonetheless, based on the description herein, persons with the present invention, gatekeeper/entry handler com- 
of ordinary skill in the art will appreciate a wide variety of ponent 110 checks for the presence of a session token in the 
configurations in accordance with the present invention in incoming request. Use of session tokens is described in 
which non-browser clients, automated agents or other sys- 30 greater detail below; however, in short, a session token may 
terns interact with enterprise applications and/or resources be any data supplied to the client entity for use in uniquely 
190 and the security architecture using any of a variety of identifying an associated session. In general, preferred ses- 
information resource identification schemes. sion token implementations are cryptographically secured 

Focusing then on an exemplary browser-type client entity, and include facilities, such as expiration or mapping to a 

browser 170 requests access to one or more of enterprise 35 particular connection, to limit risk of replay attack and/or 

applications and/or resources 190 (e.g., information resource spoofing. Some session token implementations may encode 

191) by presenting an URL to gatekeeper/entry handler session, principal, and/or trust level information. Some 

component 110, which acts as a point of entry for client session token implementations may employ cookies, URL 

entities requesting access to applications and/or resources encoding, or other similar techniques for binding to incom- 

controlled by the security architecture. Gatekeeper/entry 40 ing requests. 

handler component 110 receives the request as a proxy for In some configurations, session tokens are employed to 

the requested resource. In some configurations, a combined facilitate session continuity and to allow the security archi- 

gatekeeper/entry handler instance is provided, while in lecture to associate prior authentication of login credentials 

others, separate and/or multiple instances are provided with with an incoming access request. In one utilization, session 

functionally identical interfaces to other components of the 45 tokens are issued to client entities as part of an interaction 

security architecture. In some configurations, multiple with the security architecture and are thereafter presented 

instances of entry handler functionality (e.g., interception of with access requests. In some configurations, new session 

inbound requests and collection of environment tokens (each corresponding to a single session) are issued to 

information) are provided. For example, one or more client entity on each credential level change. In other 

instances for each of several connection types (e.g., dialup, 50 configurations, a session token may remain the same even as 

WAN, etc.) may be employed. One or more instances of credential levels are changed. Session continuity means the 

gatekeeper functionality (e.g., allowing access for autho- maintenance of coherent session state across one or more 

rized requests and otherwise denying or initiating appropri- interactions between an entity and an information environ- 

ate responsive action) may also be provided. Configurations ment. 

and functional decompositions suitable to a particular envi- 55 Components of session state (e.g., in some configurations, 
ronment and expected load requirements will be appreciated principal id, session id, authenticated trust level, group ids 
by persons of ordinary skill in the art. and/or roles, creation time, expiration time, etc.) are main- 
Entry handler functionality (e.g., in gatekeeper/entry han- tained or advanced throughout the duration of a session, 
dler component 110) ascertains much of the requesting Typically, aspects of session state are represented internally 
client's environment information. For example, for dial-up 60 by the security architecture and a session token (e.g., a 
connections, environment information such as line speed session id encoded in a cryptographically secured session 
and low-level line encryption are ascertained. Additional token) allows the security architecture to reference into the 
information, such as source number (e.g., from caller id internal representation. However, in some configurations, at 
information or based on a callback configuration), signaling least some aspects of session state may be represented or 
type (e.g., POTS or digital ISDN), etc., may also be 65 duplicated in the session token. For example, a principal id 
obtained. For network connections, similar environment and current trust level are encoded in one realization of a 
information (e.g., source network and/or node, Virtual Pri- cryptographically secured session credential and associated 
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session token or cookie. In general, a variety of facilities, In general, there is an implicit, base level of environment 

such as cookies, can be used to maintain state across a series inherent in an authenticated trust level; however, in some 

of protocol interactions, such as HTTP transactions, that do configurations, a particular authorization transaction may 

not otherwise support persistent session state. dig deeper into environment information before responding. 

Referring again to FIG. 1, if a session token is present in 5 For example, in configurations providing log-up 

the incoming request, gatekeeper/entry handler component capabilities, an authorization service will typically redirect 

110 resolves the token to a session object. Alternatively, if no l0 a k)gin service if the trust level associated with current 

session token is present or if a session token is invalid, session credentials ^ iasuffic i ent f or a requested access, 

gatekeeper/entry handler component 110 establishes a new However, for sensitive applications in such a configuration, 

"TSPi a ° CXemplary ^nfiguration in accordance 1Q an inadequate trust level may result in a REFUSED message 

with FIG. 1, session management component 160 allocates . . . nmmr^rj j- i 

a new session and supplies associated default session ere- rather than a log-up REDIRECT depending on the particular 

dentials (2) based on the requested information resource and sec f^ ^^P 1 ^ 0111 ^; , r 

environment information. Note that a session is created A REDIRECT response is used to forward the access 

irrespective of authentication status or identity, although rec l uest t0 lo S in component 120 so that sufficient login 

some implementations may refuse to even allocate a session 15 credentials may be obtained and authenticated to achieve the 

based on particular information resource requests and/or required trust level for the requested access. Note that in 

environment information. Given a session object, which some configurations, both initial login credentialing and 

may be resolved from a received session token or newly credential upgrade are provided using the REDIRECT facil- 

allocated, gatekeeper/entry handler component 110 interacts ity. In response to a REDIRECT response (4), gatekeeper/ 

(3, 4) with authorization component 140 to determine 20 entry handler component 110 redirects (5) browser 170 to 

whether the requested access is authorized. For some login component 120. In one configuration, gatekeeper/entry 

requested accesses and security policies (e.g., anonymous handler component 110 issues a client-side redirect via 

ftp access to certain archives), even a session without HTTP location directive to forward the request to login 

authenticated login credentials (trust level=0) may be autho- component 120. Parameters such as required trust level, 

rized. For others, a more substantial trust level may be 25 reqU ested URL and credential passing method can be 

required. encoded in the redirect URL and supplied (6) by browser 

Gatekeeper/entry handler component 110 supplies autho- 170 lQ lo in component 120 . Alternatively, some parameters 

rization component 140 with an identifier for the requested caR be d (5A) di|ccfl ( mrou fa a Ht tpSession 

resource (e.g., the requested URL) and an identifier for the 4 v u , ^ ' , & *• * * j 

■ j . ' 7 r , , . , . . j object) although a stateless configuration is preferred, 

associated session. Preferably, the associated session iden- _ A ■ * i - j* u 

tifier is cryptographically secured (e.g., as a signed session 30 £ session token is passed to browser 170 1 id .conjunction 

credential) In some configurations, the signed session ere- Y (5) * ^ ™ m ? 0nQnt ° D ^ 

dential is obtained from the corresponding session object. In description herein, persons of ordinary skill in the art will 

the case of a pre-existing session, the signed session ere- appreciate a number of suitable mechanisms for passing the 

dential may be obtained using a received session token. In session token, including those based on cookies and URL 

any case, authorization component 140 receives (3) the 35 encoding. Preferably, mechanisms employed are based on 

requested resource and session identifiers and responds (4) facilities provided by commercially available browsers (e.g., 

in accordance with the trust level requirement of the in accordance with HTML 3.x, 4.x or other de-facto 

requested resource. In configurations for which sensitivity to standards), although customized or plug-in facilities for 

a changing environment is desired, environment information receiving and supplying session token may be employed. In 

may also be supplied to authorization component 140. In an 40 one suitable configuration, the session token is cryptographi- 

exemplary configuration, authorization component 140 cally secured and encoded in a cookie placed at browser 170 

responds with an ALLOW, REDIRECT, or REFUSE using a set cookie directive embedded in the redirect. Other 

response based on the sufficiency of a current trust level. In configurations may use a less persistent session identifica- 

some configurations, authorization component 140 dynami- lion method, such as passing an identifier or session token in 

cally calculates a current trust level based on the signed 45 the redirect URL without storage at browser 170. Still other 

session credentials and environment information. In others, configurations may transmit a session token, a session 

authorization component 140 may base its ALLOW, credential, or identifier such as a session handle for storage 

REDIRECT, or REFUSE response on a "current" trust level in a medium such as a smart card. In configurations provid- 

previously associated with the signed session credentials. ing credential upgrade, persistent session identification 

Generally, an access request with sufficient current trust 50 methods are generally preferred, even for a not yet authen- 

level is ALLOWED and forwarded (14) without further ticated client entity, for consistency of approach. Note that 

authentication. An authorization request without proper although the identity of the client entity may not be authen- 

parameters (e.g., without a specified information resource or ticated to a sufficient level of trust, the redirected request 

without a properly secured session credential) may be includes a session token that at least identifies the session. 

REFUSED. Authorization requests associated with a client 55 Other configurations may omit the binding of session tokens 

entity that has been blacklisted or for a resource for which to sessions of not yet authenticated client entities, though 

the associated client entity cannot be authenticated using any with some increase in complexity of login component 120. 

available method to achieve the required trust level may also Browser 170 sends (6) login component 120 a new access 

be REFUSED. For example, a given security policy and request using the URL specified in the redirect from 

associated trust level mappings may dictate a REFUSE 60 gatekeeper/entry handler component 110. In configurations 

response in response to an access request lo a sensitive employing cookies as a medium for passing session tokens, 

resource (such as financial data) by any client entity (even a the new access request will include the cookie and therefore 

browser supplying the digital certificate for the CFO, and the session token. Note that in configurations in which the 

therefore presumably operating on behalf of the CEO) if the security architecture controls access to resources in several 

access request is received over a dial-up line and originates 65 domains, care should be exercised to select a tag or tags for 

from an unknown number or is received outside of working the cookie such that it will be provided through normal 

hours. operation of the browser in subsequent accesses to any of the 
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several domains. Persons of ordinary skill in the art will 
appreciate suitable tagging techniques, including the use of 
multiple cookies. Login component 120 receives the access 
request and determines an appropriate authentication 
scheme based on mapping rules that identify those authen- 
tication schemes which are sufficient to achieve a given trust 
level. Preferably, the mapping rules are a function of envi- 
ronment information. In some configurations, mapping rules 
are implemented as fuzzy sets wherein acceptable authen- 
tication schemes are a function of required trust level and 
environment information. In this way, environment affects 
the set of authentication schemes sufficient to meet a trust 
level requirement. 

Generally, mapping rule logic is evaluated before a user 
is challenged to authenticate. Mapping occurs as a function 
of session environment and particulars of the information 
resource for which access is requested. By evaluating the 
minimum trust level required by the target of an access 
request, a service (e.g., a login service such as provided by 
login component 120) derives a list of potential authentica- 
tion methods. The service then checks current session envi- 
ronment against the allowed environment states for each 
potential authentication method to trim the list further. If 
there is no particular resource for which access is being 
requested (e.g., if a user jumps straight to a sign-on page 
without requesting an access), the service will proceed 
according to the lowest level of trust available consistent 
with session environment. Other configurations may employ 
differing default behaviors. 

In some configurations, login component 120 queries (7) 
authorization component 140 to identify the set of authen- 
tication schemes that meet or exceed the required trust level 
given a current environment. In other configurations, the 
mapping is performed by login component 120. In either 
case, login component 120 supplies (9) information to 
browser 170 to allow the user to select from the suitable 
authentication schemes and to provide an associated login 
credential. In some configurations, login component 120 
supplies browser 170 with a login page (e.g., HTML) that 
prompts the user for an application specific user ID and a 
choice of authentication schemes. Interactions with browser 
170 depend on the set of credential types that, if 
authenticated, would be sufficient to meet the trust level 
requirement for access to the requested resource. For 
example, if more than one type of credential would be 
sufficient, login component 120 may interactively allow a 
user to select from amongst the credential types (e.g., using 
any HTML-based dialog). Once a particular credential type 
has been selected, login component 120 interacts with 
browser 170 to obtain an instance of the login credential to 
establish the identity of the browser user. 

Some credential types (e.g., usem name/password pairs, 
onetime passwords, enigma challenge, etc) may be obtained 
through an interactive process in which the user supplies the 
login credential(s) entry into an HTML form browser 170 
POSTs form contents back to login component 120. Others 
(e.g., digital certificates) may be supplied (10) for the client 
entity from browser 170, or in some configurations, may be 
obtained from or via an agent or certificate authority. A 
personal digital certificate (such as those issued by 
Verisign™, Thwate, Entrust or other certificate authority) 
may be obtained from a browser 170 using an HTTP 
certificate request. Although credentials may be transacted 
in a variety of ways, credentials are typically obtained from 
a user. Typically, the obtaining is indirect by asking the 
user's browser to complete the negotiation process. In such 
configurations, certificate-based authentication may be 
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transparent to the user. In some configurations, further 
authentication can be performed by using information 
encoded within the certificate to query a certificate authority 
for current status or a lookup to an authentication database 

5 may be performed for more detailed requirements. In an 
exemplary configuration, the more detailed information 
could relate to session environment or could force an 
additional name/password authentication as part of the cer- 
tificate authentication chain. In a particular implementation 

io such facilities can be provided by mapping rule encodings 
that require successful authentication using multiple authen- 
tication methods to achieve a given trust level. 

Once login credentials have been obtained by login com- 
ponent 120, they are supplied (11) to gatekeeper/entry 

15 handler component 110 for authentication. In configurations 
in which both gatekeeper/entry handler component 110 and 
login component 120 have access to a shared object such as 
the HttpSession object, login credential passing via the 
shared object is suitable. In other configurations, an HTTP 

20 POST may be employed. In an exemplary configuration, the 
particular credential passing method is selected as part of the 
original HTTP redirect (e.g., encoded in the redirect URL) 
although other configurations need not allow for a selection 
or may employ other facilities for selection of a credential 

25 passing method. 

Login component 120 also passes control of the access 
request back to gatekeeper/entry handler component 110. In 
an exemplary configuration, login component 120 issues a 
new HTTP request (11) specifying the originally requested 

30 URL, which has been stored in the HttpSession object. As 
before, gatekeeper/entry handler component 110 receives 
the request. Gatekeeper/entry handler component 110 
extracts the login credentials from the request or from the 
HttpSession object and passes (12) the login credentials to 

35 authentication component 130 for authentication. Authenti- 
cation component 130 authenticates the login credential, and 
if successful, queries (13) identification component 150 to 
establish a correspondence with a set of entity descriptors 
that uniquely identifies the requesting entity. In an exem- 

40 plary configuration, entity descriptor types include: entity id, 
system id (e.g., name/password), certificate, enigma id, 
smartcard token, name/address, and phone. One or more of 
values may uniquely identify an entity and one or more 
entity descriptor types may support multiple values (e.g., 

45 multiple digital certificates, name/password pairs, or phone 
numbers per identity). Once the requesting entity has been 
identified (14), session parameters are updated (15) and 
session management component 160 supplies (16).session 
credentials. Preferably, session credentials are digitally - 

50 signed or otherwise cryptographically secured and returned 

(17) to gatekeeper/entry handler component 110. 
Gatekeeper/entry handler component 110 again supplies 

(18) authorization component 140 with an identifier for the 
requested resource (e.g., the requested URL) and an iden- 

55 tifier for the associated session (e.g., the signed session 
credentials, authorization component 140 responds with an 
ALLOW, REDIRECT, or REFUSE response based on the 
sufficiency the session credentials (and underlying authen- 
tication of login credentials) for the trust level required for 

60 the requested access. Login credentials should now be 
sufficient for access to the requested resource and an 
ALLOW response is supplied (19) by authorization compo- 
nent 140. Gatekeeper/entry handler component U0 proxies 
the requested access (20, 21) to information resource 191 

65 and streams (22) results back to login component 120. Login 
component 120, in turn, streams (23) results back to browser 
170. 
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In some embodiments in accordance with the present 
invention, session continuity is facilitated by supplying a 
session token to browser 170. For example in one 
configuration, login component 120 supplies a session token 
using a set cookie directive encoded with the results 
streamed (23) back to browser 170. In response, browser 
170 stores the cookie using a tag (typically a filename 
encoding). Browser 170 supplies the cookie (and the session 
token) with subsequent access requests based on a corre- 
spondence between the tag and the requested resource. 
Typically, the correspondence is based on the second-level 
domain (e.g., sun.com) in which the requested resource is 
hosted, although nth-level domains or other resource iden- 
tification and session token associating schemes may be 
employed. In configurations in which the security architec- 
ture controls access to multiple domains across which a 
spanning single sign-on is desired, multiple cookies may be 
employed. 

Although the encoding of session tokens using cookies is 
presently preferred, in part because cookie facilities are 
widely supported and reasonably well accepted, other facili- 
ties may be employed to establish session continuity. For 
example, alternative URL encodings and/or custom or plug- 
in support for session identifier receipt, storage and supply 
may be employed. Also, some configurations may employ 
lower-level session identifiers, e.g., as provided by a par- 
ticular connection type such as trusted caller id information 
or as associated with a low-level line encryption or virtual 
private network infrastructure. As such facilities are likely to 
be connection-type specific, it is envisioned that they may be 
used in conjunction with other session identifier facilities 
described above, e.g., session tokens encoded in cookies. In 
one configuration, the unique Ethernet MAC address asso- 
ciated with a network interface card may be employed as a 
session handle. The MAC address is then used to associate 
with a particular set of session credentials maintained by a 
central authority. In general the representation of a session 
handle can take may forms. 

Referring again to FIG. 1, subsequent access requests 
(e.g., access request 1A) include a previously assigned 
session token. As described above, gatekeeper/entry handler 
component 110 uses the session token, if provided to resolve 
a session object containing session credentials, and to deter- 
mine whether previously authenticated credentials are suf- 
ficient for the requested access. As described above, autho- 
rization component 140 may be queried using session 
credentials and an identifier for the requested resource to 
determine sufficiency of previously authenticated creden- 
tials. In some configurations, sufficiency is determined using 
trust level mappings as described above. Depending on the 
information resource to which access is requested, and in 
some configurations depending on current session environ- 
ment information, access request 1A may or may not have 
associated previously authenticated credentials sufficient to 
support the requested access. In the case of an access request 
1A having a trust level requirement commensurate with 
previously obtained and authenticated credentials (i.e., an 
access request for which no additional credentials need be 
obtained via login component 120), the access request is 
proxied (20) and results (21) are streamed directly (23A) 
back to browser 170. In some configurations, gatekeeper/ 
entry handler component 110 supplies an updated session 
token using a set cookie directive encoded with the results 
streamed (23 A) back to browser 170. An updated session 
token, if supplied, resolves to the same session object as the 
session token replaced. For example, in some 
configurations, both session tokens encode a same session 
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handle, although other aspects associated with session token 
security such as expiration may be updated. In other 
configurations, results (21) are streamed (23A) back to 
browser 170 without an updated session token. In such 

5 configurations, the previously supplied session token 
remains valid until expired or otherwise invalidated. Some 
variations may employ a session token refresh interval. 

Depending on the information resource to which access is 
requested, previously obtained and authenticated login cre- 
dentials may be insufficient for the trust level requirement 
associated with requested access 1A. As before, authoriza- 
tion component 140 supplies gatekeeper/entry handler com- 
ponent 110 with an ALLOW, REDIRECT or REFUSE 
response based on the trust level accorded based on the 
previously obtained and authenticated login credentials and 

15 on the trust level requirement associated with requested 
access 1A. Advantageously, authorization of individual 
access requests is streamlined by the encoding of trust level 
in a cryptographically secured session credential or token. In 
the case of insufficient credentials, a REDIRECT response is 

20 supplied and gatekeeper/entry handler component 110 again 
redirects (5) browser 170 to login component 120. Addi- 
tional login credentials are obtained as described above with 
reference to initial credentials. Upon successful 
authentication, access request is proxied (20) and results 

25 (21) are streamed (23A) back to browser 170. 

Preferably, gatekeeper/entry handler component 110 sup- 
plies an updated session token using a set cookie directive 
encoded with the results streamed (23A) back to browser 
170. An updated session token, if supplied, resolves to the 

30 same session object as the session token replaced. As a 
result, session state (including e.g., identity mappings, 
authorizations, roles, permissions, environmental variables, 
etc.) is maintained through the credential level change. 
However, in the case of a credential upgrade, the session 

35 object now encodes a login credential successfully authen- 
ticated to achieve a higher trust level. In one advantageous 
configuration, the achieved (higher) trust level is encoded in 
a cryptographically secured session token representation as 
a cookie streamed (23A) back to browser 170 with results 

40 (21). 

FIG. 2 illustrates operation of an exemplary security 
architecture providing a single sign-on facility with trust 
level mapping to authentication requirements. As before, an 
access request is received (201) from a client entity. If the 

45 request does not contain a session identifier (e.g., a session 
key or token) or if the request can otherwise be reliably 
associated with a session maintained by the security 
architecture, a new session is created (202). A trust level 
requirement is determined for access to the requested 

50 resource in the context of the requesting session environ- 
ment. In some configurations, as described above, the deter- 
mination is performed by an authorization service such as 
authorization component 140. Given a trust level 
requirement, current session credentials are evaluated (203) 

55 in the context of session environment information to deter- 
mine whether the previously supplied login credentials are 
sufficient to achieve the required trust level. In one advan- 
tageous realization of session credentials and tokens, a 
cryptographically secured encoding of trust level allows 

60 authorization to be confirmed without involvement of an 
authentication service (e.g., with reauthenticalion of login 
credentials). In the case of a newly created (202) session, the 
authorization evidenced by session credentials will typically 
be insufficient, although some security policies may allow 

65 anonymous access to certain resources. 

For a pre-existing session, i.e., for an access request that 
can be reliably associated with a persistent session by a 
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cryptographically secured session token or otherwise, ses- 140. A trust level requirement is mapped (209) to at least one 
sion credentials may or may not be sufficient for access to authentication scheme sufficient to achieve the requirement 
the currently requested resource. For example, after a first based on current trust level mappings and, if employed in the 
access, the identity of an entity accessing resources con- mapping rules, based on current environment information, 
trolled by the security architecture will be authenticated to a 5 Assuming that at least one authentication scheme is avail- 
trust level sufficient for that access. Depending on the trust able that, if successful, will support the required trust level, 
level requirements of a subsequent access and, in some login credentials of that type are obtained (210) for the entity 
configurations, depending on then current trust level map- and authenticated (211). Some credential types (e.g., 
ping rules and environment information, the level of trust username/password pairs, onetime passwords, enigma 
associated with a current session (e.g., as evidenced by 10 challenge, etc) may be obtained through an interactive 
current session credentials) may or may not be sufficient for process in which a principal (e.g., a human user) supplies the 
the subsequent access. In situations for which a current level credentials) entry in an HTML form and POSTs form 
of trust (e.g., resulting from prior authentication of login contents back to the credential gathering service. Others 
credentials for an entity associated with the session) is (e.g., certificates) may be obtained for the client entity from 
sufficient for later access to the same or to another infor- 15 an agent or authority. For example, a personal digital cer- 
mation resource, access is allowed without additional tificate (such as those issued by Verisign™, Thwate, Entrust 
authentication. For example, in some security architectures or other certificate authority) may be obtained from a 
in accordance with the present invention, the security archi- browser using an HTTP certificate request. In some 
tecture proxies (204) the request to the requested informa- configurations, a choice of credential types may be provided 
tion resource and streams (205) a resulting response back to 20 and user may select from a set of credential types sufficient 
the requesting client entity. for the requested access. Once appropriate login credentials 
As described elsewhere herein, sufficiency of current have been obtained and authenticated, the session corre- 
session credentials is determined using mapping rules that, sponding to the requested access is updated (213) to reflect 
in some realizations, include environment information. In the new authenticated session credentials. The now suffi- 
general, current session credentials may be insufficient (1) 25 ciently authorized request is proxied (204) and results are 
because the identity of the requesting client has not yet been streamed back (205) to the requesting client entity. Updated 
authenticated (e.g., in a first access situation), (2) because of or refreshed session credentials are typically supplied as a 
a higher trust level requirement for the requested access, or session token (e.g., a cookie) encoded with the streamed 
(3) because of a change in mapping rules or environment results. 

that causes a previously sufficient credential no longer be 30 FIG. 3 illustrates interactions between functional compo- 

sufficient for a particular trust level. Whatever the reason for nents in an exemplary functional decomposition of a secu- 

the insufficiency, a request corresponding to a session and rity architecture. An on-line order processing transaction is 

client entity that is insufficiently authenticated, and that is exemplary and functional boundaries are merely illustrative, 

therefore not authorized, is passed to a facility for obtaining Based on the description herein, a wide variety of suitable 

credentials of a type that, if authenticated, will support the 35 enterprise information environments and functional decom- 

required trust level. positions in accordance with the appended claims will be 

Typically, session credentials and/or an associated session appreciated by persons of ordinary skill in the art. 
token encode an expiration time (see description, below, of In the configuration of FIG. 3, application and central 
FIG. 4). In such configurations, a previously sufficient security portions (321 and 322, respectively) of the security 
session credential is insufficient after its expiration. In some 40 architecture are illustrated. Of note, functional components 
configurations, session credentials are periodically refreshed of application security portion 321 are typically hosted as 
by re authentication of the underlying login credentials. For services on a first server environment, while functional 
example, in one implementation, a presented session token components of central security portion 322 are hosted as 
indicating expiration in less than five (5) minutes causes the services on a second server environment. In this way, most 
security architecture to reauthenticate (not shown) underly- 45 interactions amongst functional components occur within a 
ing login credentials stored in a corresponding SessionOb- single server environment and do not require network trans- 
ject (e.g., under the private key of authentication component actions. In the configuration of FIG. 3, credentials associated 
130). Reauthentication typically results in a new session with a calling component (e.g., framework credentials asso- 
credential and associated trust level. Depending on then ciated with application security framework 303 or applica- 
instant mapping rules, the associated trust level may or may 50 tion credentials associated with order management service 
not be sufficient. Also, reauthentication may fail if the login 312) are used to establish sufficient authorization for net- 
credentials have been invalidated, revoked or if the login work transactions. Other configurations may be employed, 
credentials have expired. Assuming that reauthentication of however, the relatively small number of network transac- 
login credentials is successful, updated session credentials tions(e.g., authentication transaction 331 and optional value 
are issued, for example, by authentication component 130 55 passing transaction 332) tends to improve performance of 
and supplied (e.g., as a cookie encoded session token) to the the security architecture. Of note, authentication transaction 
client entity e.g., browser 170). 331 need only be performed on login credential authentica- 

Referring again to FIG. 2, a request corresponding to a tion (e.g., at initial sign-on or credential upgrade) or reau- 
session not authorized for a requested access is redirected thenticated (e.g., to refresh session credentials). Value pass- 
(206) to a credential gathering service (e.g., login compo- 60 ing transaction 332 provides an optional facility for passing 
nent 120). The credential gathering service receives (207) values amongst multiple components of a distributed appli- 
the redirected access and obtains (208) a trust level require- cation (e.g., a distributed implementation of order manage- 
ment for the requested access. In some configurations, the ment service 312) wherein application credentials are used 
trust level requirement may be passed with the redirected to mediate storage and retrieval of values in a central 
access or otherwise associated with the redirected access, in 65 registry. 

others the trust level requirement may be re-obtained from User 301 interacts with browser 302 to place an order with 

an authorization service such as authorization component order management service 312. An application security 
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framework 303 receives an access request including the requesting entity is sufficiently authorized to access order 
order and, operating in conjunction with a variety of other management service 312, a login credential gathering pro- 
services, provides a single sign-on facility substantially as cess is initiated. Based on the required trust level and on 
described above. If the order does not include a session mies that encode the sufficiency of authentication schemes, 
token or cannot be otherwise associated with corresponding 5 a login credential is obtained from user 301 and/or browser 
valid session credentials, then session credentials are 302 . The obtained login credential is of a type that, if 
obtained. As illustrated in FIG 3, session credentials are authenticated, is sufficient to meet the trust level requirement 
obtained using login credentials (e.g a username/password fof access tQ 0fder management service 312 . Aspects of an 
pair a digital certificate, etc.) Typically, an access request exem pi ary credential gathering process are described in 
without session credentials -wil not have associated login ^ Hq ^ ^ FIG. 3 
credentials. As a result, and default login credentials (e.g., r„ ^ 4 . . . . c . r . . _ 
identity=anonymous) are used during initial phases of a illustrates the obtaining of a username/password pair. Once 

single sign-on process. Nonetheless, in some configurations, lo S m . cre <^ tials f e °* ame ?' the J P 85 * f to c f ntral 
login credentials may be provided with an initial access secunl y framework 304 (as described above) for authenti- 
request. More typicaUy, an initial access request is received callon b * central authentication service 307 so that session 
by application security framework 303 without session 15 credentials can be obtained, the requested access can be 
credentials or without prior presentation and authentication authorized, and the order processing initiated. Signed ses- 
of login credentials sufficient to access the requested sion credentials, typically embodied as a cryptographically 
resource. In response to credential gathering operations, a secured session token that may be stored as a cookie, are 
subsequent request is made with login credentials that passed back to browser 302 with results of the requested 
purport to be sufficient, if authenticated, to meet the trust 20 access. In this way, subsequent access requests are identified 
level required for access to order management service 312. as part of a session and authorization may be quickly 
In such a case, session credentials are obtained by passing confirmed without unnecessary reauthentication. 
login credentials to a central security framework 304. Some configurations in accordance with the present 
Authorization of application security framework 303 for invention employ session credentials as a mechanism for 
access to components of the central security portion 322 is 25 evidencing prior authentication of obtained login credentials 
checked by query to central authorization service 306. and for binding individual transactions to a particular ses- 
Assuming that framework credentials evidence sufficient sion. In some configurations, session credentials are also 
authorization, login credentials are authenticated by central employed in a session token form advantageous for trans- 
authentication service 307. Central authentication service actions external to the security architecture. In an exemplary 
307, in turn, interacts with central principal registry 310 to 30 realization, session tokens are encoded for supply to brows- 
establish the identity and group membership of user 301 and ers as cookies. FIG. 4 illustrates relationships between 
with central session registry 311 to create a persistent exemplary login credential, session credential and session 
session for subsequent accesses by user 301. Particulars of token objects. 

the request are logged to central audit service 308 and, if As described above, login credentials (e.g., represented in 

authentication was successful, session credentials are 35 a form such as exemplary login credentials structure 410) 

returned to application security framework 303. are obtained for a client entity. Typically, login credentials 

Signed session credentials are presented to application encoded in login credentials structure 410 are obtained from 

authorization service 313 together with an identifier for the a principal via browser client and serve as evidence that the 

requested resource and optionally with an identifier for a principal (e.g., a human user) is entitled to a particular 

particular function or facility of the requested resource. In 40 identity. Accordingly, login credentials structure 410 

response, application authorization service 313 checks the encodes a use rid and a domainld within which the userld 

authorization of the principal (e.g., of user 301) associated should uniquely correspond to a principal. Specific login 

with the session credentials to access the requested resource. credentials, e.g., a password, a certificate, results of a 

Application authorization service 313 interacts with appli- biometric process, a response to an Enigma challenge or 

cation resource registry 314 to identify trust level require- 45 results of a smart card interrogation, etc. are encoded in 

ments for the requested resource (and in some login credentials structure 410, as a tagged value. An authen- 

con figurations, for a particular function or facility of the ticationScheme is specified and creation time may be 

requested resource) and determines the sufficiency of a encoded to limit replay attacks. In the implementation of 

current trust level evidenced by the session credential. Note FIG. 4, login credentials structure 410 is encrypted using the 

that trust level is assessed by inspection of the session 50 public key of an authentication service (e.g., of authentica- 

credential and without interaction with an authentication tion component 130). Because the key is public, any 

service. In some configurations (e.g., as illustrated in FIG. component, even untrusted components may encrypt login 

3), group membership is also evaluated as part of the credentials for provision to authentication component 130, 

authorization check. while only authentication component can decrypt the 

If the signed session credentials indicate that the request- 55 encrypted login credentials using its private key. In some 

ing entity, e.g., browser 302 on behalf of user 301, is configurations, secure transfer protocols, e.g., SSL, are 

sufficiently authorized to access order management service employed to secure login credentials between a client entity 

312, a Create Order request is passed to order management such as browser 170 and the security architecture while 

service 312 and order processing proceeds in accordance encryption with a public key of an authentication service is 

with normal handling thereof. Additional accesses may be 60 performed within the security architecture, e.g., at login 

required, e.g., to select delivery options or to confirm some component 120. In other configurations, encryption with a 

aspect of the order. Assuming that the additional accesses do public key of an authentication service may be performed at 

not require a higher trust level, they will be passed to order the client entity. 

management service 312 based on the correspondence of If the encrypted login credentials provided to an authen- 

session credentials with trust level requirements. 65 tication service are determined to be authentic, session 

If an exception is thrown due to insufficient authorization, credentials are issued. In the implementation of FIG. 4, 

e.g., if the signed session credentials do not indicate that the session credentials are embodied in a form such as exem- 
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plary session credentials structure 420. Encrypted and clear authentication methods as described elsewhere herein, 

text portions (421 and 422) of session credentials structure However, in some embodiments, an authorization encoding 

420 allow contents of the session credential to be read by may establish that a principal has been authenticated using 

anyone and changed by no one (except the authentication a particular authentication mechanism. In either case, an 

service possessing a private key). Contents of encrypted 5 authorization (e.g., encoded as a trust level) in a crypto- 

portion 421 correspond to that clear text portion 422 but are graphically secured session credential allows the security 

encrypted using the private key of the authentication service architecture to authorize accesses based on prior authenti- 

(e.g., of authentication component 130). Of note, principal cation of a login credential and without involvement of the 

ids, authorizations and other contents encoded in the session authentication service. Group ids can be used to grant or 

credential may be read by components of the security io limit authorization scope based on group membership, 

architecture, and in some embodiments by components Typically, session credentials serve as evidence of prior 

external to the security architecture. Such components can authentication and authorization for multiple accesses to 

verify the authenticity of information stored in clear text information resources controlled by the security architec- 

portion 422 using encrypted portion 421 and a public key ture. However, session credentials may be replaced on a 

corresponding to the private key of the authentication ser- 15 login credential upgrade as described elsewhere herein. In 

vice. Of note, the information contained in a session ere- addition, session credentials of limited temporal validity 

dential is generally not sensitive. What is sensitive is the may be refreshed by periodic replacement. In the configu- 

state of the information. Therefore, security architectures ration of session credentials structure 420, creation time and 

employing facilities described herein ensure that informa- expiration time allow the security architecture to improve 

tion contained in the session credential is provably constant 20 resistance to replay attacks. Session credentials typically 

once set by an authentication service. By using the public have a relatively short expiration time (e.g., 15 minutes from 

key of the authentication service, which will in general be creation or less) and underlying login credentials will be 

freely available, together with the encrypted information, reauthenticated prior to expiration of the session credential, 

any application can read the information (e.g., in free text) Assuming that the underlying login credentials, which are 

and ascertain that the session credential was created by the 25 stored under the public key of authentication component 

authentication service and that the session credential has not 130, remain valid, authentication component 130 will issue 

been tampered with. Assuming that the authentication ser- a replacement cryptographically secured session credential 

vice's private key has not been compromised, tampering (e.g., as session credentials structure 420). Depending on 

with the session credential will result in a decryption failure. then current trust level mappings and, in some 

In an alternative implementation (not shown), session 30 configurations, depending on then current environment 

credentials may be digitally signed and verified by a public parameters, the authorization accorded by the security archi- 

key corresponding to a private key. In such an alternative tecture and encoded as a trust level may differ from that 

implementation, the digital signature also allows contents of encoded in the session credential replaced. If a principal id 

the session credential to be read by anyone and changed by or login credential has been revoked, reauthentication may 

no one. For some configurations, the implementation of FIG, 35 fail and a user may be prompted to supply a sufficient login 

4 is preferred because encrypted portion 421 can be used as credentials as described elsewhere herein. Session id and 

an externally supplied session token. Such a session token principal id will typically remain the same for successive 

representation is a compact representation of the session session credentials associated with a single persistent scs- 

credential particularly appropriate for encoding as a cookie sion. 

placed at a browser and returned with subsequent access 40 As previously described, one advantage of the approach 

requests. employed in session credentials structure 420 is that 

Referring again to session credentials structure 420, a encrypted portion 421 may also be employed as a compact 

session id, a principal id, a trust level, group ids, a creation session token representation 430 of session credential for 

time and an expiration time are encoded in both in encrypted use as a cookie. In one embodiment in accordance with FIG. 

portion 421 and clear text portion 422. The session id is a 45 4, encrypted portion 421 is a string encoded representation 

unique identifier for a persistent session maintained by the of approximately 200 characters which may be placed at a 

security architecture. In implementations in which credential browser (e.g., via transfer 5, 23 or 23A of FIG. 1) using a set 

upgrade is provided or in which a session credential expi- cookie directive, 

ration and refresh is provided, multiple successively issued Exemplary Implementations 

session credential instances may encode the same session id 50 In an exemplary embodiment, at least some of the above- 
and correspond to the same persistent session. Principal id described components are implemented as servlets execut- 
encodes an identifier for a principal to which the security able in the context of a commercially-available web server 
architecture has resolved login credentials. For example, a environment. For example, the Java™ Embedded Server 
login credential including a username jdoe and a password (JES) architecture with extensions for certificate handling, 
corresponding to jdoe may be resolved by the security 55 HyperText Transfer Protocol (HTTP), Simple Network 
architecture to a unique principal id associated with John. Q. Management Protocol (SNMP), Secure Sockets Layer 
Doe of the shipping and receiving department, having an (SSL), extensible Markup Language (XML) grammar pro- 
employee badge number of 12345, etc. cessing and security Access Control List (ACL) support 
In some embodiments, a trust level encodes the authori- available from Sun Microsystems, Inc. is one suitable envi- 
zation level to which a principal has been authenticated. In 60 ronment. Java and all Java-based marks and logos are 
such embodiments, the encoded trust level serves as a basis trademarks or registered trademarks of Sun Microsystems, 
for evaluating whether a principal associated with the ses- Inc. in the United States and other countries, 
sion credentials has been authenticated to a sufficient level In general, the description herein is focused on aspects of 
for access to a requested resource. For example, a trust level a security architecture, rather than on peculiarities of a 
of 5 may be sufficient for access to information resources 65 particular implementation environment. It is envisioned that 
having a trust level requirement of 5 or less. Trust levels security architectures in accordance with the teachings of the 
offer an attractive decoupling of authorization levels and present invention may be implemented in the context of 
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many commercially-available networked information ser- 
vice environments, including web server environments, as 
well as in custom environments and environments that in the 
future will be developed. However, to facilitate an under- 
standing of broad concepts using a specific exemplary 5 
environment, and without limitation, the description herein 
may include terminology specific to the Java Embedded 
Server (JES) architecture. Nonetheless, based on this 
description, persons of ordinary skill in the art will appre- 
ciate implementations suitable for other environments. The 10 
scope of the invention, as defined by the claims that follow, 
is not limited to any specific implementation environment. 

While the invention has been described with reference to 
various embodiments, it will be understood that these 
embodiments are illustrative and that the scope of the ^ 
invention is not limited to them. Many variations, 
modifications, additions, and improvements are possible. 
For example, the set of authentication schemes described 
herein is illustrative and embodiments in accordance with 
the present invention may include others, including those 2 o 
that may be hereafter developed. If employed, rules mapping 
trust levels to authentication schemes may be encoded in a 
variety of ways depending on the particular implementation. 
In general, such mapping rules may be encoded as static or 
dynamic table associating trust level to authentication 2 5 
schemes. Alternatively, mapping rules may be encoded as 
predicates or in other declarative forms. Mapping rules may 
be encoded in a weighted logic or fuzzy set form. 
Additionally, particular mappings may depend environment 
information. Furthermore, evaluation of mapping rules may 30 
be performed in a variety of functional components such as 
an authorization service, a credential gathering service or a 
gatekeeper. Session continuity may be provided using cryp- 
tographically secure session tokens passed as cookies or by 
other mechanisms. 35 

In some configurations, a session token is a compact 
encrypted representation of at least selected contents of a 
session credential. Other compact representations corre- 
sponding to a session credential may be employed. 
Alternatively, the same representation of session credentials 40 
may be employed both within the security architecture and 
outside the security architecture (e.g., at a browser or other 
client). Suitable contents of a session credential (and session 
token, if employed) will be appreciated by persons of 
ordinary skill in the art based on the description herein of 45 
specific examples. 

More generally, plural instances may be provided for 
components described herein as a single instance. Finally, 
boundaries between various components, services, servlets, 
registries and frameworks are somewhat arbitrary, and par- 50 
ticular operations are illustrated in the context of specific 
illustrative configurations. Other allocations of functionality 
are envisioned and may fall within the scope of claims that 
follow. Structures and functionality presented as discrete 
components in the exemplary embodiments) may be imple- 55 
mented as a combined structure or component. These and 
other variations, modifications, additions, and improve- 
ments may fall within the scope of the invention as defined 
in the claims that follow. 

What is claimed is: 60 

1. A method of determining sufficiency of a credential 
type for access to an information resource, the method 
comprising: 

establishing a correspondence between a session and an 
access request targeting the information resource; 65 

establishing a trust level requirement for access to the 
information resource; and 
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evaluating correspondence of one or more credential 
types with the trust level requirement for access to the 
information resource and with environment informa- 
tion associated with the session. 

2. A method as in claim 1, 

wherein one or more authenticated credentials of the one 
or more credential types are associated with the ses- 
sion; and 

wherein the correspondence evaluating includes deter- 
mining whether at least one of the one or more authen- 
ticated credentials is sufficient to achieve the trust level 
requirement given the environment information. 

3. A method as in claim 2, further comprising: 

if at least one of the one or more authenticated credentials 
is sufficient to achieve the trust level requirement given 
the environment information, allowing the requested 
access; and 

otherwise, obtaining and authenticating a sufficient cre- 
dential before allowing the requested access. 

4. A method as in claim 1, 

wherein the correspondence evaluating includes deter- 
mining a set of the credential types sufficient to achieve 
the trust level requirement given the environment infor- 
mation. 

5. A method as in claim 4, further comprising: 
obtaining at least one credential of a type selected from 

the set of sufficient credential types; 
authenticating a client entity thereby; and 
performing the requested access on behalf of the client 

entity. 

6. A method as in claim 1, 

wherein the correspondence evaluating includes evaluat- 
ing a mapping rule encoding suitable credential types 
as a function of trust levels and environment param- 
eters. 

7. A method as in claim 1, 

wherein the session correspondence establishing includes 
use of a cryptographically secured session token 
encoded with the access request to resolve the session 
and the environment information. 

8. A method as in claim 1, further comprising: 
coincident with receipt of the access request, updating the 

environment information associated with the corre- 
sponding session. 

9. A method as in claim 1, 

wherein the environment information includes one or 
more of connect location, access request time, access 
request date, session start time, session start date, client 
type and client capabilities. 

10. A method as in claim 1, 

wherein the session includes a dial-up connection; and 
wherein the environment information includes one or 
more of connection speed and low-level line encryp- 
tion. 

11. A method as in claim 1, wherein the environment 
information includes one or more of source identifier and 
signaling type. 

12. A method as in claim 1, 

wherein the session includes a network connection; and 
wherein the environment information includes one or 
more of source network, source node, Virtual Private 
Network (VPN) low-level encryption and routing infor- 
mation. 
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13. A method as in claim 1, 

wherein the set of the credential types includes one or 
more of a usemname password pair, digital certificate, 
an encrypted credentials based on asymmetric, 
symmetric, public, private, or secret key technology, a 5 
one-time password, a biometric credential based on 
retinal scan, voice print, or finger print, and a posses- 
sion based credential embodied in a smart card, Enigma 
card or physical key. 

14. A method as in claim 1, 10 
wherein the trust level requirement establishing includes 

querying an authorization service with a resource iden- 
tifier for the information resource targeted by the access 
request and with a session identifier for the correspond- 
ing session. 15 

15. A method as in claim 1, embodied as a computer 
program product including functionally descriptive informa- 
tion for directing a processor to perform the correspondence 
establishing, the trust level requirement establishing, and the 
evaluating, the computer program product encoded by or 20 
transmitted in at least one computer readable medium 
selected from the set of a disk, tape or other magnetic, 
optical, or electronic storage medium and a network, 
wireline, wireless or other communications medium. 

16. A method of operating a security architecture, the 25 
method comprising: 

matching an access request of a client entity with a 
corresponding session, the access request targeting a 
first of plural information resources and the session ^ 
having an associated one or more session parameters 
affecting sufficiency of credential types; 

determining a set of one or more credential types suffi- 
cient for access to the first information resource, the 
determining based, at least in part, on the one or more 35 
session parameters; 

if an authenticated credential associated with the session 
is of one of the sufficient credential types, then allowing 
access to the first information resource; and 

otherwise, 40 
obtaining a new credential and authenticating the client 
entity thereby, the obtained credential being of one of 
the sufficient credential types; and 
allowing access to the first information resource. 

17. A method as in claim 16, wherein the determining of 45 
sufficient credential types includes: 

obtaining a trust level requirement associated with the 
first information resource; 

selecting only those credential types sufficient, if 
authenticated, to achieve the trust level requirement 50 
given current values of the one or more session param- 
eters. 

18. A method as in claim 16, wherein the determining of 
sufficient credential types includes: 

evaluating decision logic encoding the set of sufficient 55 
credential types as a function of the session parameters 
and particular one of the information resource for 
which access is requested. 

19. A method as in claim 17, wherein the decision logic 

is encoded at least partly as one of: 60 
mapping rules; 
fuzzy sets; and 

session parameter-based trust level discounts; and 

an enumeration of trust level and session parameter 65 

minima corresponding to individual of the credential 

types. 
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20. A method as in claim 16, wherein the determining of 
sufficient credential types includes: 

evaluating decision logic encoding the set of sufficient 
credential types as a function of the session parameters 
and a trust level requirement associated with the tar- 
geted information resource. 

21. A method as in claim 16, 

wherein the one or more session parameters are indicative 
of temporal, locational or connection-related states of 
the matched session. 

22. A method as in claim 16, 

wherein the client entity includes a browser; and 
wherein the matching of the access request with the 
session includes use of a cryptographically secured 
session token encoded in cookie supplied to the 
browser. 

23. An information system comprising: 

plural information resources hosted on one or more serv- 
ers coupled via a communication network to a client 
entity, the plural information resources having indi- 
vidualized authentication requirements; and 

an access control facility common to the plural informa- 
tion resources, the common access control facility 
obtaining a credential for the client entity and authen- 
ticating the client entity thereby; 

wherein, in response to a request for access to a first of the 
information resources, the common access control 
facility evaluates, based in part on current parameters 
of a corresponding persistent session, sufficiency of 
associated authenticated credentials for access to the 
first information resource. 

24. An access control facility for providing a single 
sign-on for sessions that potentially include accesses to 
plural information resources having differing security 
requirements, the access control facility comprising: 

an application proxy for receiving an access request 
targeting one of the information resources, associating 
the access request with a session, and selectively 
proxying the access request; 

means responsive to the application proxy for evaluating 
sufficiency of credential types based on then current 
parameters of the session and on a trust level require- 
ment of the targeted information resource, the applica- 
tion proxy proxying the access request if at least one 
sufficient credential is associated with the session. 

25. An access control facility as in claim 24, further 
comprising: 

credential gathering means responsive to an insufficient 
zero or more credentials associated with the session, 
the credential gathering means obtaining a credential of 
type sufficient, if authenticated, to achieve the trust 
level requirement of the targeted information resource 
given then current parameters of the session. 

26. An access control facility as in claim 24, embodied as 
a computer program product encoded by or transmitted in at 
least one computer readable medium selected from the set of 
a disk, tape or other magnetic, optical, or electronic storage 
medium and a network, wireline, wireless or other commu- 
nications medium. 



